Summary

Fixes datatable operations in PostgreSQL deployments using non-public schemas by replacing hardcoded 'public' schema references with current_schema.

Related Issues

• Resolves FINERACT-2468

Description

When using PostgreSQL with tenant-specific schemas (non-public), creating a new datatable causes:

1. GET /datatables to return 404 with "Datatable not found"
2. Saving data to the datatable to fail with "Datatable not found"

Root Cause: getTableIndexes() and isTablePresent() in PostgreSQLQueryService.java hardcoded 'public' schema while getTableColumns() correctly used current_schema, causing inconsistent table discovery in GenericDataServiceImpl.

Solution: Modified both methods to use current_schema instead of hardcoded 'public', ensuring all table metadata queries use the connection's current schema.

Changes Made

• PostgreSQLQueryService.getTableIndexes(): Changed schemaname = 'public' to schemaname = current_schema
• PostgreSQLQueryService.isTablePresent(): Changed table_schema = 'public' to table_schema = current_schema

Testing Performed

• ✅ All unit tests pass (93/93 in fineract-core module)
• ✅ Manual PostgreSQL verification with non-public schema confirms fix
• ✅ Verified current_schema query finds indexes while 'public' query doesn't (reproduces original bug)

Manual Verification:

CREATE SCHEMA tenant_abc;
SET search_path TO tenant_abc;
CREATE TABLE dt_test_table (id SERIAL PRIMARY KEY, client_id INTEGER);
CREATE INDEX idx_dt_test_client ON dt_test_table(client_id);

-- Fixed query (works):
SELECT indexname FROM pg_indexes WHERE schemaname = current_schema AND tablename = 'dt_test_table';
-- Result: Returns 2 indexes ✅

-- Old buggy query (fails):
SELECT indexname FROM pg_indexes WHERE schemaname = 'public' AND tablename = 'dt_test_table';
-- Result: Returns 0 rows ❌

Impact

• Behavior Change: None for single-tenant 'public' schema deployments (current_schema defaults to 'public')
• Fix: Enables datatable operations in multi-tenant PostgreSQL deployments with custom schemas

Checklist

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Notes

• No API changes - internal database query fix only
• No Swagger updates needed
• Changes are minimal (2 SQL queries) and surgical
• GPG-signed commit included